MIDI usage and applications
Many extensions of the original official MIDI 1.0 specification have been jointly standardized by the MIDI Manufacturers Association (MMA) in the US and the Association of Musical Electronics Industry (AMEI) in Japan. General MIDI (GM) was an attempt by the MIDI Manufacturers' Association (MMA) to standardize an instrument programme number map.
Later, companies in Japan's AMEI developed General MIDI Level 2 (GM2), which extended the instrument palette, specified more message responses, and defined new messages. GM2 became the basis of the instrument selection mechanism in Scalable Polyphony MIDI (SP-MIDI), a MIDI variant for mobile applications. In addition to the original 31.25 kBaud current-loop, 5-pin DIN transport, transmission of MIDI streams over USB, IEEE 1394 a.k.a FireWire, and Ethernet is now common. MIDI is also used every day as a control protocol in applications other than music, including for show control and theatre lighting.
Contents |
Extensions of the MIDI standard
Many extensions of the original official MIDI 1.0 specification have been jointly standardized by the MIDI Manufacturers Association (MMA) in the US and the Association of Musical Electronics Industry (AMEI) in Japan. Only a few of them are described here; for more comprehensive information, see the MMA web site.
General MIDI
The General MIDI (GM) and General MIDI 2 (GM2) standards define a MIDI instrument's response to the receipt of a defined set of MIDI messages. As such, they allow a given, conformant MIDI stream to be played on any conformant instrument. Although dependent on the basic MIDI 1.0 specification, the GM and GM2 specifications are each separate from it. As such, it is not generally safe to assume that any given MIDI message stream or MIDI file is intended to drive GM-compliant or GM2-compliant MIDI instruments.
At heart, these specifications resolve certain ambiguities in the MIDI message protocol. In MIDI, instruments (one per channel) are selected by number (0-127), using the Program Change message. However, the basic MIDI 1.0 specification did not specify what instrument sound (piano, tuba, etc.) corresponds to each number. This was intentional, as MIDI originated as a professional music protocol, and in that context it is typical for a performer to assemble a custom palette of instruments appropriate for their particular repertoire, rather than taking a least-common-denominator approach.
Eventually interest developed in adapting MIDI as a consumer content format, and for computer multimedia applications. In this context, in order for MIDI file content to be portable, the instrument program numbers used must call up the same instrument sound on every player. General MIDI (GM) was an attempt by the MIDI Manufacturers' Association (MMA) to resolve this problem by standardising an instrument programme number map, so that for example Program Change 1 always results in a piano sound on all GM-compliant players. GM also specified the response to certain other MIDI messages in a more controlled manner than the MIDI 1.0 specification. The GM spec is maintained and published by the MIDI Manufacturers' Association (MMA).
From a musical perspective, GM has a mixed reputation, mainly because of small or large audible differences in corresponding instrument sounds across player implementations, the limited size of the instrument palette (128 instruments), its lowest-common-denominator character, and the inability to add customised instruments to suit the needs of the particular piece. Yet the GM instrument set is still included in most MIDI instruments, and from a standardisation perspective GM has proven durable.
General Midi 1 was introduced in 1991.
General MIDI 2
Later, companies in Japan's AMEI developed General MIDI Level 2 (GM2), incorporating aspects of the Yamaha XG and Roland GS formats, extending the instrument palette, specifying more message responses in detail, and defining new messages for custom tuning scales and more. The GM2 specs are maintained and published by the MMA and AMEI.
General MIDI 2 was introduced in 1999 and last amended in February 2007.
SP-MIDI
Later still, GM2 became the basis of the instrument selection mechanism in Scalable Polyphony MIDI (SP-MIDI), a MIDI variant for mobile applications where different players may have different numbers of musical voices. SP-MIDI is a component of the 3GPP mobile phone terminal multimedia architecture, starting from release 5.
GM, GM2, and SP-MIDI are also the basis for selecting player-provided instruments in several of the MMA/AMEI XMF file formats (XMF Type 0, Type 1, and Mobile XMF), which allow extending the instrument palette with custom instruments in the Downloadable Sound (DLS) formats, addressing another major GM shortcoming.
Alternate Hardware Transports
In addition to the original 31.25 kBaud current-loop, 5-pin DIN transport, transmission of MIDI streams over USB, IEEE 1394 a.k.a FireWire, and Ethernet is now common (see below).
MIDI over Ethernet
Compared to USB or FireWire, the Ethernet implementation of MIDI provides network routing capabilities, which are extremely useful in studio or stage environements (USB and FireWire are restricted to connections between one computer and some devices and do not provide any routing capabilities). Ethernet is moreover capable of providing the high-bandwidth channel that earlier alternatives to MIDI (such as ZIPI) were intended to bring.
After the initial fight between different protocols (IEEE-P1639, MIDI-LAN, IETF RTP-MIDI), it appears that IETF's RTP MIDI specification for transport of MIDI streams over Ethernet and Internet is now spreading faster and faster since more and more manufacturer's are integrating RTP-MIDI in their products (Apple, CME, Kiss-Box, etc...). Mac OS X, Windows and Linux drivers are also available to make RTP MIDI devices appear as standard MIDI devices within these operating systems.
RTP-MIDI Transport Protocol
The RTP-MIDI protocol has been officially released first in public domain by IETF in December 2006 (RFC 4695). It was obsoleted by RFC 6295 in June 2011, which fixes errors of the old RFC. RTP-MIDI relies on the well-known RTP (Real Time Protocol) layer (most often running over UDP, but compatible with TCP also), widely used for real-time audio and video streaming over networks.
RTP layer is extremely easy to implement and requires very little power from microprocessors, while providing very useful information to the receiver (network latency, loss of packets, reordered packets, etc...). RTP-MIDI defines a specific payload type, that allows the receiver to identify MIDI streams.
RTP-MIDI does not alter the MIDI messages in any way (all messages defined in the MIDI norm are transported transparently over the network), but it adds some specific functionalities, like timestamping and sysex fragmentation. RTP-MIDI also adds a very powerful mechanism, named journaling, that allows the receiver to detect the loss of MIDI messages in the network, but also to retrieve lost information.
The first part of the RTP-MIDI specification is mandatory and describes how MIDI messages are encapsulated within the RTP telegram. It also describes how the journaling system is working. It must be noted that the use of the journaling system is not mandatory (journaling is not very useful for LAN applications, but it is very important for WAN applications).
The second part of RTP-MIDI specification describes the session control mechanisms that allow multiple stations to synchronize across the network to exchange RTP-MIDI telegrams. This part is informational only, and it is not required that all RTP-MIDI implementations use the described mechanisms.
RTP-MIDI is included in Apple's Mac OS X since 10.4 and iOS since 4.2, as standard MIDI ports (the RTP-MIDI ports appear in Macintosh applications as any other USB or FireWire port. Thus, any MIDI application running on Mac OS X is able to use the RTP-MIDI capabilities in a transparent way). However, Apple's developers have considered that the session control protocol described in IETF's specification was by far too complex, and they created their own session control protocol. Since the session protocol uses a different UDP port of the main RTP-MIDI stream port, the two protocols do not interfere (so the RTP-MIDI implementation in Mac OS X fully complies to the IETF specification).
Apple's implementation has been used as reference by other MIDI manufacturers. A Windows XP RTP-MIDI driver specifically for their own devices has also been released by the Dutch company Kiss-Box, another Windows RTP-MIDI driver[1] compatible to Windows XP up to Windows 7 (32bit and 64bit) has also been released and a Linux implementation is currently under development by the Grame association. It is then quite probable that Apple's implementation will become the "de-facto" standard (and could even become the MMA reference implementation).
[1] IETF RTP-MIDI specification RFC 4695
[2] Windows XP RTP-MIDI driver download http://www.kiss-box.com
[3] Grame's website http://www.grame.fr
Alternate Tunings
By convention, instruments that receive MIDI generally use the conventional 12-pitch per octave equal temperament tuning system. Unfortunately this tuning system makes many types of music inaccessible because the music depends on a different intonation system. To address this issue in a standardized manner, in 1992 the MMA ratified the MIDI Tuning Standard, or MTS. This standard allows MIDI instruments that support MTS to be tuned in any way desired, through the use of a MIDI Non-Real Time System Exclusive message.
MTS uses three bytes, which can be thought of as a three-digit number base 128, to specify a pitch in logarithmic form. The following formula gives the byte values needed to encode a given frequency in hertz:
For a note in A440 equal temperament, this formula delivers the standard MIDI note number. Any other frequencies fill the space evenly.
Support for MTS is not particularly widespread in commercial hardware instruments. Prograsm that do support MTS include the free software programs TiMidity and Scala, as well as other microtuners.
Other applications of MIDI
MIDI is also used every day as a control protocol in applications other than music, including:
- show control
- theatre lighting
- special effects
- sound design
- Console automation
- recording system synchronization
- audio processor control
- computer animation
- computer networking, as demonstrated by the early first-person shooter game MIDI Maze, 1987
- animatronic figure control
Such non-musical applications of MIDI are possible because any device built with a standard MIDI Out connector should in theory be able to control any other device with a MIDI In port, just as long as the developers of both devices have the same understanding about the semantic meaning of all the MIDI messages the sending device emits. This agreement can come either because both follow the published MIDI specifications, or else in the case of any non-standard functionality, because the message meanings are agreed upon by the two manufacturers.
MIDI controllers which are hardware and software
Note: The term MIDI controller is used in two different ways. (1) In one sense, a MIDI controller is a hardware or software entity able to transmit MIDI messages via a MIDI Out connector to other devices with MIDI In connectors. (2) In the other (more technical) sense, a MIDI controller is any parameter in a device with a MIDI In connector that can be set with the MIDI Control Change message. For example, a synthesizer may use controller number 18 for a low-pass filter's frequency; to open and close that filter with a physical slider, a user would assign the slider to transmit controller number 18. Then, all changes in the slider position will be transmitted as MIDI Control Change messages with the controller number field set to 18; when the synthesizer receives the messages, the filter frequency will change accordingly.
The following are classes of MIDI controller (using definition 1 above):
- The human interface component of a traditional instrument redesigned as a MIDI input device. The most common type of device in this class is the keyboard controller. Such a device provides a musical keyboard and perhaps other actuators (pitch bend and modulation wheels, for example) but produces no sound on its own. It is intended only to drive other MIDI devices. Percussion controllers such as the Roland Octapad fall into this class, as do guitar-like controllers such as the SynthAxe and a variety of wind controllers.
- Electronic musical instruments, including synthesizers, samplers, drum machines, and electronic drums, which are used to perform music in real time and are inherently able to transmit a MIDI data stream of the performance.
- Pitch-to-MIDI converters including guitar/synthesizers analyze a pitch and convert it into a MIDI signal. There are several devices which do this for the human voice and for monophonic instruments such as flutes, for example.
- Traditional instruments such as drums, pianos, and accordions which are outfitted with sensors and a computer which accepts input from the sensors and transmits real-time performance information as MIDI data.
- Sequencers, which store and retrieve MIDI data and send the data to MIDI enabled instruments in order to reproduce a performance.
- The MIDI Show Control (MSC) protocol (in the Real Time System Exclusive subset) is an industry standard ratified by the MIDI Manufacturers Association in 1991 which allows all types of media control devices to talk with each other and with computers to perform show control functions in live and canned entertainment applications. Just like musical MIDI (above), MSC does not transmit the actual show media — it simply transmits digital data providing information such as the type, timing and numbering of technical cues called during a multimedia or live theatre performance.
- MIDI Machine Control (MMC) devices such as recording equipment, which transmit messages to aid in the synchronization of MIDI-enabled devices. For example, a recorder may have a feature to index a recording by measure and beat. The sequencer that it controls would stay synchronized with it as the recorder's transport controls are pushed and corresponding MIDI messages transmitted.
MIDI controllers in the data stream
Note: The term MIDI controller is used in two different ways. (1) In one sense, a MIDI controller is a hardware or software entity able to transmit MIDI messages via a MIDI Out connector to other devices with MIDI In connectors. (2) In the other (more technical) sense, a MIDI controller is any parameter in a device with a MIDI In connector that can be set with the MIDI Control Change message. For example, a synthesizer may use controller number 18 for a low-pass filter's frequency; to open and close that filter with a physical slider, a user would assign the slider to transmit controller number 18.
This section uses the second definition of "MIDI controller".
Performance modifier controls such as modulation wheels, pitch bend wheels, sustain pedals, pitch sliders, buttons, knobs, faders, switches, ribbon controllers, etc., can alter an instrument's state of operation, and thus can be used to modify sounds or other parameters of music performance. Because MIDI includes messages for representing such controller events, they can be sent in real time over MIDI connections. MIDI makes approximately 120 virtual controller numbers (addresses) available for this purpose, i.e. connecting the actual buttons, knobs, wheels, sliders, etc. with their intended actions within the receiving device. In MIDI, the value data range of the Control Change message is 128 steps (0 to 127), and the first 32 controller numbers (including, for example, Volume) are allocated an additional 7 bits of "Least Significant Bits" precision for a total of 14 bits or a range of 0-16383 (although many manufacturers do not implement this increased resolution).
Some controller functions, such as pitch bend or key pressure, are special, with a dedicated MIDI data range of 16,384 steps. This higher resolution makes it possible to, for example, produce the illusion of a continuously sliding pitch, as in a violin's portamento, rather than a series of zippered steps such as a guitarist sliding fingers up the frets of the guitar's neck. At the MIDI message stream level, pitch bend and key velocity use different, dedicated messages (Polyphonic Key Pressure, Channel Pressure, or Pitch Bend Change) instead of the ordinary Control Change message. There is a trade-off, however: the pitch wheel and/or key pressure functions of a MIDI keyboard can, depending on the performance, generate large amounts of data which can in turn lead to a slowdown of data throughput on the MIDI connection. This can be remedied by using a sequencer to "thin" pitch-bend (or any other continuous controller) data down to only a limited number of messages per second, or down to only messages that change the controller value by at least a certain amount.
The original MIDI spec included approximately 120 virtual controller numbers for real time modifications to live instruments or their audio. MIDI Show Control (MSC) and MIDI Machine Control (MMC) are two separate extensions of the original MIDI spec, expanding the MIDI protocol to become far more than its original intent.